Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.026

Text File | 1996-02-12 | 29KB | 633 lines

Frequently Asked Questions (FAQS);faqs.026



A16: Using XDV.COM, DESQview Classic or DESQview-386 can load most of itself
     into upper and high memory so conventional memory is preserved. However,
     loading many TSRs or DOS high (see Q22) will reduce the amount of
     DESQview that can be loaded high (i.e. in the XMA - the first 64K of
     extended memory).  DVX386 automatically loads itself into high memory.

     DESQview also sets aside a portion of conventional memory and calls it
     ``Common Memory''.  The amount that DESQview allocates can be decreased
     in DVSETUP, but the minimum is about 14K.  Certain programs such as DVSI
     (a set of shareware utilities by Daniel Bodoh) require the amount of
     Common Memory to be larger than the minimum.  A large Open Window menu
     or many ``shared programs'' will also increase the required amount of
     Common Memory.

     Each window has an area of memory called ``System Memory''.  The amount
     of System Memory available to a program is controlled by three separate
     entries on the Change A Program screen.  First, since DESQview stores
     the window image in System Memory, decreasing the number of text pages
     and maximum window size decreases System Memory usage.  Second, since
     most programs do not explicitly use System Memory, the System Memory
     field can be set to 1K or 0K.

     The pool of System Memory only reduces the maximum window memory for
     that particular window, and does not affect the other windows.  You can
     see this using the Memory Status program.  It will report, say, 592K of
     conventional memory available, but part of that is used for System
     Memory so the actual amount available is less.

     QW:161:WINSIZE.TEC, QW:252:MAXWINDO.TEC
---------------------------------------------------------------------------
Q17: What are some programs that are incompatible with DESQview?


A17: [Please forward any other known incompatibilities to the editor of this
     FAQ list (see above).]
     Any ``386 Control Program'' that is not VCPI compliant (see Q15).

     BitFax

     Borland C++ 3.0
     Borland has a patch on Compuserve and the Borland BBS.  This patch is
     also available on SIMTEL20 as DPMIFI.ZIP in PD1:<MSDOS.CPLUSPLUS> (see
     Q7).

     Colorado Memory Systems, Inc.'s TAPE.EXE
     Incapable of finding a tape drive piggybacked to a floppy adapter when
     run in a DVC window. It does not crash the system, but backups are not
     possible when inside DESQview.  Colorado will be fixing this in the
     future.  Under DVX, it can find the tape drive.

     ConFormat

     Diagnostic programs that try to go into protected mode to tested
     extended memory will fail under QEMM.  These include QAPLUS and RAMTEST.
     Diagnostic programs should be run from a boot floppy.

     DJGPP/DJGPP-compiled programs
     Finally, DJGPP 1.09 available via anonymous FTP from
     BARNACLE.ERC.CLARKSON.EDU [128.152.28.12] in /pub/msdos/djgpp, works
     with DESQview/X (and probably DESQview, too). For those of you who don't
     know, DJGPP is a full 32-bit C/C++ compiler for DOS with a DOS extender
     which allows you to use *all* your 386 memory and your disk as memory.
     DJGPP 1.09 can compile X windows programs written for DESQview/X with
     the companion X libraries (see Q8).

     DR DOS 6.0 history feature
     DR DOS works great with DESQview, except for the history feature.

     DVFormat by SLR Systems
     Has problems with DESQview/X which Quarterdeck are trying to fix.

     Games that use digitized sound without extra sound hardware.  Digitized
     sound requires that the timer interrupt be sped up to 8000 or more
     interrupts per second, which DESQview can't deal with.  The only
     workaround is to turn off the sound or buy extra sound hardware.

     Micronics rev 1.10.05 and 1.10.06 motherboards with Phoenix BIOS
     Incompatible with QEMM-386.  The first rev that worked again with QEMM
     was 1.10.10.  Contact Phoenix for a BIOS upgrade.

     Mountain FileSafe 4000 Tape Backup Software

     Microsoft C/C++ 7.00
     MSC requires a DPMI host which until now QEMM did not provide. You can
     now use QDPMI to allow QEMM to become a DPMI host.

     MS-Kermit 3.11
     Try setting Optimize Communications in DVSETUP to No.  If that doesn't
     work, use the Kermit SET COM command to set the exact interrupt request
     and I/O port used.  The problem will be fixed in 3.12.

     QA Plus (see above note on Diagnostic programs)

     RAMTEST (see above note on Diagnostic programs)

     Soundblaster
     Games that use Soundblaster require ``Share CPU'' be set to N or the
     music will be choppy.  Some games do work OK, though.

     Speed (LandMark Tests 2.00)
     Crashes DESQview

     Windows Enhanced Mode
     (see Q11)
---------------------------------------------------------------------------
Q18: I'm having a problem {configuring DESQview, running a program, etc.}.
     How do I fix it?


A18: First of all, take a look at the manual.  This may seem obvious, but
     you'd be surprised at the number of people that post problems which they
     could have solved themselves by glancing at the manual.

     If you still can't figure it out, post a complete description of your
     problem.  Don't just say, for example, ``foo.exe doesn't run''.  Be
     specific.  Post the Change A Program screens, or portions of
     AUTOEXEC.BAT or CONFIG.SYS if relevant.  But use some restraint.  Don't
     post 18 pages of system configuration information just because you can't
     get foo.exe to print ``Hello, world''.
---------------------------------------------------------------------------
Q19: How can I contact Quarterdeck?


A19: Quarterdeck Office Systems
     150 Pico Boulevard
     Santa Monica, CA, USA 90405

     Technical Support:
          Phone:    [phone]
          Fax:      [phone]
     Sales:
          Phone:    [phone]
          Fax:      [phone]
     Customer Service or Orders:
          Phone:    [phone]

     QOS BBS:  [phone] (24 hours/day, 1200-9600, HSD 14.4k and V32bis,
     8 bits, No parity)

     E-mail (for Tech Support):
          Internet/Usenet/UUCP: [e-mail]
          Quarterdeck BBS:    Sysop
          CompuServe:         76004,2310
          BIX:                QOS.REP2
          MCI Mail:           QUARTERDECK
          Smartnet:           DESQview Conference - Quarterdeck USA

     Public Message forums for Quarterdeck Tech support:
          QOS BBS:       <T>echnical Support Message System
          CompuServe:    ``GO QUARTERDECK''
          BIX:           ``JOIN DESQVIEW''
          SmartNet:      DESQview Conference
          FidoNet:       DESQview Echo (currently no QOS support online)
          RelayNet:      DESQVIEW - Quarterdeck USA or Quarterdeck Canada
          ILINK:         Multitaskers
          Usenet:        comp.os.msdos.desqview - QOS techs are active

     Ireland
     -------
     European Headquarters
     Quarterdeck International Ltd.
     B.I.M. House, Crofton Terrace
     Dun Laoghaire, Co.
     Dublin, Ireland
     Phone:    [phone]
     Fax:      [phone]
     BBS:      [phone]
     QFAX:     [phone]
     Product Information/Registration Cards:
     Phone:    [phone]
     Fax:      [phone]


     United Kingdom
     --------------
     Quarterdeck Office Systems UK Ltd.
     Widford Hall, Widford Hall Lane,
     Chelmsford, Essex, CM2 8TD, United Kingdom
     Technical Support
     Phone:    + 4471 973-0663
     Fax:      + 4471 973-0664
     BBS:      + 4471 973-0661
     QFAX      + 4471 973-0665
     Product Information/Upgrade/Registration Cards:
     Phone:    + 44 245 496699
     Fax:      + 44 245 495284
     BBS:      + 44 245 263898


     Canada
     ------
     Quarterdeck Office Systems Canada, Inc.
     70 York St., Suite 1220
     Toronto, Ontario M5J 1S9
     Phone:    [phone]
     Fax:      [phone]
     Upgrades: [phone]


     Germany
     -------
     Quarterdeck Office Systems GmbH
     Willstaetter Strasse 15
     D-4000 Duesseldorf 11
     Germany
     Technical support:
     Phone:    +49 211 / 59790-40
     Fax:      +49 211 / 59790-60
     QFAX      +49 211 / 59790-65
     Product info, upgrades:
     Phone:    +49 211 / 59790-0
     Fax:      +49 211 / 594126

     France
     ------
     Quarterdeck Office Systems S.A.R.L.,
     4, Rue de General Lanrezac, 75017 Paris, France.
     Technical Support
     Phone:  Int + 33 144-09-03-40
     Fax:      + 33 144-09-00-69
     BBS:      + 33 144-09-01-07
     QFAX:     + 33 144-09-00-81
     Product Information/Upgrade/Registration Cards
     Phone:    + 33 144-09-03-91
     Fax:      + 33 144-09-03-47


     Cyprus / Eastern Mediterranean
     ------------------------------
     Quarterdeck Office Systems Middle East Ltd.
     1 Souliou Street, Suite 103, Strovolos,
     Nicosia, Cyprus.
     Product Information/Upgrade/Registration Cards/Support
     Phone:    + 357 2311-630
     Fax:      + 357 2311-560


     Spain
     -----
     Quarterdeck Office Systems S.A.,
     Gran Via de les Courts, Catlanes, 617, 10-3A
     08007 Barcelona, Spain.
     Product Information/Upgrade/Registration Cards/Support
     Phone:    + 343-412-29-45
     Phone:    + 343-412-44-41
---------------------------------------------------------------------------
Q20: What books are available on DESQview?


A20: ``DESQview - A Guide to Programming the DESQview Multitasking
          Environment'', by Stephen R. Davis, M&T Books Publishing, 501
          Galveston Drive, Redwood City, CA 94063. 346 pages. 1st Edition,
          1989.
     [This is a review from Quarterdeck.  I've heard from others that this
     books is really not that good and doesn't have many examples.  Look it
     over well before you spend any money.] A very good source on programming
     in C using the DESQview API.  This is a tutorial book with lots of
     examples.  Would be useful to programmers who find the QOS API manuals
     somewhat daunting.  All examples are in C, however there is lots of
     general information  which would be useful for developers programming in
     any language.   Available direct from M&T and bookstores which
     specialize in technical works.  Can be ordered from Quarterdeck order
     line at [phone] for $24.95 ($39.95 with disk - 5 1/4 inch only).

     ``The Official DESQview Sourcebook'', Larry Joel Goldstein, Bantam
          Computer Books, 666 Fifth Ave., New York, NY 10103. 351 pages. 1st
          edition - Sept. '89, price $22.95 ($27.95 Canada).
     A comprehensive guide to the use of DESQview, QEMM and the  DESQview
     Companions.  Contains a section on the DESQview API that  may serve as
     an introduction, but this is not a programmer's book.  A useful adjunct
     to the Quarterdeck manuals when you want similar information from
     another view.

     ``DOS Beyond 640K'', Second Ed. James Forney, Windcrest Books, Division
          of TAB Books Inc., Blue Ridge Summit, PA 17294-0850. 1989.  235
          ISBN 0-8306-9717-9, ISBN 0-8306-3744-3 pbk. pages.  Price $19.95.
     Not a DESQview/QEMM book specifically, but an excellent book on  the
     subject of memory, with many references to DESQview and QEMM. Highly
     recommended to users who really want to understand the use of memory in
     their PCs.

     ``The Best Book of DESQview'', Jack Nimersheim, Howard W. Sams &
          Company,  11711 North College, Suite 141, Carmel, IN 46032.  1st
          Edition 1990, 396 pages.  Price $24.95
     A user-friendly guide to DESQview, the Companions, QEMM and Manifest.
     Contains many tips and a good discussion of the DESQview Learn feature.

     ``Mastering DESQview'', Jonathan Kamin,  Scott, Foresman IBM Computer
          Books,  1900 E. Lake Avenue, Glenview, IL 60025.  1st Edition 1990,
          387 pages.  Price $24.95.
     A comprehensive guide to the use of DESQview, with emphasis on hints and
     techniques which enhance the use of DESQview.  Special emphasis on
     creative use of DESQview's Learn (macro) facility.

     ``Extending DOS,'' Ray Duncan, Charles Petzold, M. Steven Baker, Andrew
          Schulman, Stephen R. Davis, Ross P. Nelson, Robert Moote,
          Addison-Wesley Publishing Co., Second edition, 1992.
     An excellent work on DOS memory usage and some of the options for
     extending DOS.  For advanced users and programmers.  Quite a bit of
     example source code included.  Covers IBM PC Programming Architecture,
     EMS, XMS, DOS Extenders, Windows, DESQview, VCPI, DPMI and Multitasking.

     ``DESQview Instant Reference,'' Paul J. Perry, 1991, Sybex, 166 Pages.
          Price $9.95
     This is a basic, short reference guide to DESQview, QEMM-386, and
     Manifest. It covers up to versions 2.3 of DESQview and version 5.1 of
     QEMM-386.  It describes the use of all the DESQview functions, QEMM-386
     switches, and switches for LOADHI, QEMM.COM, VIDRAM.  All the
     information provided is in the Quarterdeck manuals.

     ``Understanding DESQview,'' Richard Altman, 1991, Sybex, 307 pages.
          Price $24.95

     ``DESQview Unleashed'', Dave Williams, SAMS.
     Coming in August 1992.  Will include part of this FAQ!

     ``Memory Management for All of Us'', by John M. Goodman, Ph.D.  SAMS,
          1992. ISBN 0-672-27366-7. Price $29.95.
     Discusses virtually all aspects of PC memory and memory management,
     including how DESQview uses memory.

     ``XView Programming Manual,'' Dan Heller, etal., O'Reilly & Assoc. 586
          pages. Price:  $34.95

     ``X Window System Programming,'' Naba Barkakati, 1991, Howard W. Sams &
          Co.  600 pages.  Price:  $29.95
     Good introduction to X programming, with many helpful example programs.
     Covers xlib, xt Intrinsics, and some discussion of OSF/Motif widgets is
     provided.

     ``Introduction to the X Window System,'' O. Jones, 1989, P-H.  Price:
          $38.00

     ``The X Window System in a Nutshell'', 1990, O'Reilly & Assoc.  Price:
          $24.95


     [If you know of any more, please let me know]

     QW:132:BOOKS.TEC
---------------------------------------------------------------------------
Q21: What are the command-line switches for DESQview/QEMM/QRAM?


A21: The file QOSSWIT3.ZIP from SIMTEL20 (see Q7) in the PD1:<MSDOS.INFO>
     directory contains a list of the documented and undocumented switches
     for Quarterdeck's products.

     QW:178:ALL-HELP.TEC
---------------------------------------------------------------------------
Q22: How can I configure DESQview for maximum window memory?


A22: The answer to this question is very system dependent.  However, you
     should use QEMM rather than EMM386 and HIMEM.SYS (on a 386), because
     QEMM is smaller and will provide the same services.  Also, without QEMM
     screen virtualization is not possible (see Q2).  Loading DOS high will
     not necessarily help, because that reduces the amount of DESQview kernel
     that can be loaded high (see Q16).

     When you test using DOS=HIGH, make sure you add I=0800-0FFF to QEMM
     line. This will allow QEMM to map the area vacated by DOS, so you may
     see a gain in window size. You almost have to be using stealth to see a
     net gain.

     Also, if you don't need graphics, you can use the VREMS parameter on the
     QEMM line, and add VIDRAM ON to the DV.BAT file. This will give you
     about 64k more for each window. DV.BAT should actually have a VIDRAM ON
     before calling DV, and VIDRAM OFF after DV.

     Experiment.  Use Manifest to judge the results.  If your high memory is
     very fragmented (i.e. many small contiguous blocks rather than a few
     large blocks), keeping DOS and TSRs low and putting DESQview high might
     work better.

     Do not set up your path and environment variables until all the TSRs
     have been loaded.  A copy of the environment is made for every TSR, and
     if the TSR does not give this area of memory back to DOS, it is wasted.

     QEMM's STEALTH feature should be used if it is compatible with your
     machine.  There are three different STEALTH modes:
          ST:F - Frame stealth.  Compatible with many machines, but offers
                 the least amount of memory gain.  Also known as ``Female
                 Stealth''.

          ST:M - Mapping stealth.  It offers significantly more memory gain
                 but will not work on all machines.  Also known as ``Male
                 Stealth''.

          ST:P - Protected mode stealth.  Undocumented and unsupported by
                 Quarterdeck, because it has many incompatibilities.  If you
                 can get it to work on your machine, you could get an
                 additional 25K or so over ST:M.  You cannot run any other
                 protected mode programs with ST:P (the DVX stuff seems to
                 work, though).

     Here's a neat trick to save memory under DVX.  This is from David Granz.

     How to Maximize your memory space for programs under DVX
     ---------------------------------------------------------

     In order to use DV/X on a TCP/IP network, the FTP software TCP/IP
     drivers must be loaded.  Unfortunately, these TSRs can take up over 100K
     of precious DOS memory space.  In addition a mouse driver is needed
     (another 12-16K of memory used up).  And then, DV/X itself chews up a
     significant amount of DOS memory. Even with the new QEMM stealth
     features that allow most of the upper memory space to be used to LOADHI
     these TSRs, the memory actually left for a program (or DOS window) under
     DV/X can end up being quite small.  In my particular setup, the best I
     was able to get was a 320K DOS window.

     After much experimenting and some suggestions from Quarterdeck, I have
     come up with the following procedures that allow you get very close to a
     full 640K of program space in a DOS window (somewhat less if you don't
     have a 8514 video card).  Note that although this method seems to work
     fine (for me at least), it is not in anyway a supported method.  Please
     DO NOT call Quarterdeck for help with this setup, they are not
     supporting this technique at this time.  If you have problems with
     things crashing, put things back the way they were before, and see if
     the problems go away.  Then, if the crash still occurs, you have a valid
     reason to call Quarterdeck.

     Before doing any of the following modifications, make a safe copy of
     \DVX\STARTUP.DVP and \DVX\DVPS\PCTCP.DVP.  These copies can be used to
     restore the system in case you have problems.

     Step 1, Saving the space occupied by the MOUSE driver:
          Create a file called \DVX\SERVER.BAT that contains the following
          lines:

               MOUSE   (or whatever is needed to run your mouse)
               SERVER

          Then with the DVPMAN program (under DV/X), modify the file
          \DVX\STARTUP.DVP. Change the reference to SERVER.EXE to SERVER.BAT.
          Also increase the memory size by enough to cover the added size of
          the mouse driver (about 30k should be plenty).

          Modify your CONFIG.SYS and/or AUTOEXEC.BAT to not load the mouse
          driver when you boot your computer.

          Restart the computer, and then DV/X...  The mouse driver should now
          load in the process space of the server.

          A 'mem/c' command in a DOS window, should show more memory
          available and no copy of the mouse driver.


     Step 2, Saving the space occupied by the TCP drivers:
          In a manner similar to the above mouse modifications, you need to
          create a batch file:  \DVX\NETWORK\NETWORK.BAT.  This batch file
          should contain all the drivers and network programs needed to
          support TCP/IP.  The last step should be to run the 'nsftp'
          program.

          For example, my NETWORK.BAT looks like this:
               c:\dvx\device c:\ftp\ifcust.sys
               c:\dvx\device c:\ftp\ipcust.sys
               c:\ncsa\drivers\wd8003e -w 0x62 7 0x280 0xD000
               c:\ftp\ethdrv -t 20 -p 26 -u 2
               nsftp

          Using DVPMAN, modify the \DVX\DVPS\PCTCP.DVP parameters to run
          NETWORK.BAT rather than NSFTP.EXE.  You should add enough memory
          allocation to allow for the extra memory of the network drivers.
          In my case a 350K allocation seems to work fine but you may need
          more.

          Remove all the network drivers and TSRs from your CONFIG.SYS and
          AUTOEXEC.BAT, and reboot DOS and DV/X.

          If all goes correctly, the DOS windows under DV/X should now
          contain none of the network drivers.  With this arrangement I am
          able to get about 550K available in the DOS window.

          The only limitation of this arrangement, is that only Quarterdeck
          supplied network programs (telnet, ftp, etc) will work.  This is
          because the network drivers are running in a different address
          space than the DOS windows.  The normal FTP software's and Packet
          driver's access interrupts are not available in any process other
          than the PCTCP process.

     Step 3, Getting even more space:

          If you have a 8514 type video card (I have a ATI Graphics Ultra),
          you can get even more space for DOS programs.  As an added
          advantage, the video performance is much better with this card
          (1024x768x256).

          Add the 'VREMS' parameter to your QEMM386.SYS line in CONFIG.SYS.
          This will allow the \QEMM\VIDRAM program to steal the address space
          at A0000-AFFFF for DOS use.

          Before starting DV/X, do a "\QEMM\VIDRAM ON" command.  Just ignore
          the message that DV/X cannot find a graphics card.  DV/X will run
          just fine without this video ram area.  The DOS window will be 64K
          bigger.

          The only limitation of this, is that graphic programs (ie ones that
          take over the entire screen) must not be run.  Text programs and
          programs that use X windows calls will work just fine.

          QW:161:WINSIZE.TEC, QW:252:MAXWINDO.TEC
---------------------------------------------------------------------------
Q23: What is NOFF.SHP {NOFF.SHR}?

A23: NOFF.SHR is an older version of NOFF.SHP.  So what's NOFF.SHP?

     DESQview is the child of an older IBM program called TopView.  Because
     Quarterdeck wanted DESQview to run all the old TopView programs, they
     made DESQview compatible to TopView, in much the same way you can run
     programs written for DOS 3.3 in DOS 4.0.

     If a program writes directly to the video memory, TopView (and DESQview)
     cannot run it in a small window.  So IBM allowed programs to be TopView-
     aware (similar to DESQview-aware (see Q3)) by giving them ``virtual''
     video memory on request.  This memory looks like video memory, but
     characters written into it do not get displayed on the screen.

     Since DESQview is a much smarter program that TopView ever was, DESQview
     can automatically update the window from the virtual video memory.  But
     TopView did not have that ability.  The TopView-aware program had to
     make another call which would manually update the window from the video
     memory.

     Quarterdeck wanted to make DESQview look as much like TopView as
     possible, so they decided that if a TopView-aware program makes this
     call to update the window, then the automatic updating of DESQview would
     be turned off.

     DESQview can do a better job of updating the window from the virtual
     video buffer than *some* programs.  So the purpose of NOFF.SHP is to
     capture the TopView update call before it gets to DESQview and not let
     DESQview see the call.  That way, DESQview never turns off the automatic
     updating, and your window output is less jerky.

     Whether or not you should use NOFF.SHP depends on how the TopView-aware
     program updates its screen.  If it changes only small parts of the
     screen at a time but requests that the entire screen be updated, use
     NOFF.SHP.  But if the program tells TopView (DESQview) exactly which
     part of the screen changed, output may look smoother without NOFF.SHP
     because an automatic update doesn't take place until the end of each
     program's time slice (see Q9).

     Although NOFF.SHP is included in the Quarterdeck-supplied DVP for
     Wordperfect, it is not required if you are using a 386 or better and you
     turn on text virtualization.

     QW:247:SHARED.TEC
---------------------------------------------------------------------------
Q24: How can I increase DESQview's performance?


A24: DESQview's performance depends on many different factors.  We will try
     to highlight some of the important areas here.

     DESQVIEW-OBLIVIOUS PROGRAMS
          Performance is especially degraded by DESQview-oblivious programs
          (see Q3), because they do not give up the CPU when they are not
          doing useful work (see Q9).

          Some programs, while waiting for keyboard input, continuously ask
          if a keystroke is available instead of giving up the CPU.
          Quarterdeck provides a way to force programs to give up the CPU
          after a specified number of keystroke queries.  One of the bytes in
          the DVP file (the file edited by Change A Program) specifies the
          number of keyboard polls before the CPU is taken away.

          Unfortunately, Quarterdeck has never put a field on the Change A
          Program screens to change this number.  DvpEdit, a freeware
          replacement for Change A Program, is available on SIMTEL20 (see Q7)
          and allows you to change this ``Max Keypolls'' value.

          Another well-known program is TAME.  TAME does much more than watch
          for keyboard polling; and can do a good job of increasing
          performance.

          System performance can be measured with the PS utility available in
          the DVSI package (also on SIMTEL20 and DVNet).  Using PS, an
          offending program can be quickly identified.

     DISK ACCESS
          Since disk access can slow down the system significantly (see Q10)
          using a disk cache can also increase performance.  HyperDisk,
          available on SIMTEL20 (see Q7), is especially popular among
          DESQview users.

     FOREGROUND/BACKGROUND TICKS
          With the ``Tune Performance'' menu you can set the number of
          foreground and background ticks.  These numbers indicate how much
          time DESQview is to allocate to a given task before moving on to
          the next in a round-robin fashion. The default setting is 9:3,
          which means DESQview gives the foreground task 9 ``ticks'', or
          roughly half a second, of CPU time, then gives each of the
          background tasks 3 ticks. A more common setting with today's
          hardware is 1:1 or 2:2 -- each task gets 1 (or 2) ticks.

          There's no single, optimal setting. Smaller numbers generally
          provide smoother performance, but may overwhelm the CPU on less
          powerful systems. In addition, time-sensitive applications like
          communications programs may need to be serviced frequently by the
          CPU. In short, experiment.

          Here's an undocumented trick:  Go to ``Tune Performance'' and
          backspace to erase the numbers that are in the ticks fields.  This
          will set them to ``H0'' (next time you bring up the ``Tune
          Performance'' window).  This trick seems to set the ticks to 1/2
          and 1/2 (although this claim has been disputed -- more
          experimentation will have to be done).

          Setting 0 background ticks will cause background windows to never
          run.  Setting 0 foreground ticks will cause background windows to
          run only if the foreground window explicitly gives up its
          timeslice, or if it blocks (i.e. waits for a keystroke or other
          event).

     SCREEN DISPLAY
          There are three primary reasons why your screen may appear jerky.
          First, you may be virtualizing the window. While this prevents
          bleed-thru (when used in conjunction with QEMM-386), it does
          increase the workload on DESQview, and the screen output only
          occurs at the end of the program's timeslice. If this is a problem
          for you then configure your application to use BIOS screen writes
          and turn virtualization off. Second, you may need to adjust your
          tick settings. DESQview updates the screen display at the end of a
          task's CPU allocation. Thus, a setting of, say, 99:99 will result
          in extremely jerky screen updates compared with 2:2 or so.  Third,
          you may be unnecessarily using NOFF.SHP (see Q23).